Show ramp crypto amounts at the asset's own decimal precision - #6168
Merged
Merged
Conversation
Contributor
Author
📸 Test evidencebefore truncated at 6 decimals
after btc shows 8 decimals
after eth shows 9 decimals
Captured by the agent's in-app test run (build-and-test). |
j0ntz
marked this pull request as ready for review
August 19, 2026 23:44
j0ntz
force-pushed
the
jon/moonpay-decimal-precision
branch
from
August 19, 2026 23:44
7d5423a to
e85b6b3
Compare
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
The buy/sell amount field capped the crypto value at six decimals, which was fine while every provider quoted at or below that. MoonPay raises its buy-flow precision on September 1, 2026 (BTC to eight decimals, ETH and SOL to nine), so the cap would start silently truncating the amount the user is quoted. Derive the cap from the selected asset's denomination instead, bounded at nine decimals. Assets with more precision than a quote can express, such as ETH at eighteen, would otherwise surface the rounding noise of the float exchange rate the field divides by while a fiat amount is typed.
j0ntz
force-pushed
the
jon/moonpay-decimal-precision
branch
from
September 28, 2026 19:19
e85b6b3 to
fa6dab9
Compare
j0ntz
enabled auto-merge
September 28, 2026 19:19
Contributor
Author
|
Landing this without a review.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CHANGELOG
Does this branch warrant an entry to the CHANGELOG?
Dependencies
none
Requirements
If you have made any visual changes to the GUI. Make sure you have:
Description
Asana: https://app.asana.com/0/1215088146871429/1217660195990065
MoonPay told us it raises the decimal precision of its buy flow on
September 1, 2026. BTC goes from 5 to 8 decimals, ETH from 6 to 9 decimals, and
SOL from 3 to 9 decimals, while stablecoins stay at 2. MoonPay asked integrators to confirm they treat crypto
amounts as variable-precision decimals rather than assuming a fixed count per
asset. The sell flow is unaffected.
Audit of the live buy path (
src/plugins/ramps/moonpay/, which is what the Buytab routes to; the legacy
amountQuotePluginsits behindpluginListBuyOld):number rendered back through
Number.toString()and then handled bybiggystring, which is arbitrary precision and accepts exponent notation.
the one quote-vs-delivered comparison normalises both sides through the same
number parse, so it assumes no decimal count.
RampCreateScenerendered the cryptoamount field with
maxDecimals={6}, whichFilledTextInputapplies astoFixed(value, 0, 6), a truncation. Every MoonPay asset currently quotes at6 decimals or fewer, so the cap has never bitten; after September 1 it would
silently drop 2 digits of BTC and 3 of ETH and SOL.
This derives the cap from the selected asset's own denomination instead, bounded
at 9 decimals. That gives BTC 8, ETH 9, SOL 9 and USDC 6, matching MoonPay's new
per-asset maximums. The bound matters for assets with more precision than a
quote can carry: when the user types a fiat amount the field divides by a float
exchange rate, whose rounding noise shows up past about 9 decimals, so rendering
ETH's full 18 would surface digits that are not real.
Verified on the iOS simulator with a before and after pair on the same input,
attached below.
verify-repo.shpasses (eslint, jest, changelog).Note
Low Risk
Localized change to ramp amount input formatting; quote handling was already variable-precision and only the entry field was truncated at six decimals.
Overview
Buy/sell ramp crypto amount entry no longer hard-caps display and typing at six decimals. The field now uses
cryptoMaxDecimals, derived from the selected asset’s denomination precision viamulToPrecision, capped at nine so high-precision assets (e.g. ETH) don’t show spurious digits when fiat-driven amounts are divided by a float exchange rate.This aligns the UI with provider quote precision (e.g. MoonPay’s per-asset limits for BTC/ETH/SOL) without changing how quotes are parsed or calculated elsewhere.
Reviewed by Cursor Bugbot for commit fa6dab9. Bugbot is set up for automated code reviews on this repo. Configure here.